Coverage increased (+0.2%) to 91.612% when pulling 3b0c8c2 on new_syntax into 11f93e7 on master.

While I understand what you are trying to do, I believe the verbosity you are adding will actually lead to more code and confusion. For instance the its(:parameters) syntax could just as easily be the similar older pattern without the verbosity of its(:parameters) block. Perhaps a similar pattern to what has been adopted by serverspec in that we have it { is_expected.to have_ensure('running') } or multiple values with something like it { is_expected.to have( {:ensure => 'running' , :enabled => true }) }

How would this new format work with method chaining?

it do
  is_expected.to contain_file('/tmp/test').with({ ensure: present}).that_comes_before("File['/tmp']")
end

@cyberious 👍 I like it

@logicminds something like this

describe file('/tmp/test') do
  its(:parameters) { is_expected.to include(ensure: 'present') }
  it { is_expected.to come_before(file('/tmp')) }
end

One of the main ideas behind the new syntax is to discourage the use of long chains of methods in the expectations and instead make it easy to do small, discrete expectations on a resource. This leads to much easier to read tests and output

my::class
  File[/tmp/test]
    should be in the catalogue
    should come before File[/tmp]
    parameters
      should include {:ensure => 'present'}

@rodjek adjacent to this, a question on Slack was raised on how to test for global properties of the catalog, like, "no directory with a source should have recurse set to true". Do you see a possibility to integrate such functionality here?

@DavidS Yep, that's similar to another issue #229 where the user wants to be able to check that all cron resources have certain IO redirects in their command string. What I'm thinking is a way to enumerate resources of a particular type, so maybe something like this?

resources(:file).select { |f| f.ensure == 'directory' && f.source }.each do |file_resource|
  describe file_resource do
    it { is_expected.to have_attributes(:recurse => false) }
  end
end

It reminds me of (global) property-based testing:

describe resource(:ifile).select { ... } do
  all { are_expected.to ... }
end

Yeah, it could be written as:

describe resources(:file).select { |f| f.ensure == 'directory' && f.source } do
  it { is_expected.to all(have_attributes(:recurse => false)) }
end

That would give slightly less easy to understand output in documentation format, but a more consise test.

How would this deal with resources within a module? given the current double underscore I'd expect describe concat__fragment('x') do ... end

Another thing I'd like to see is easy verification of the full content. Currently we have helper functions:

def verify_concat_fragment_contents(subject, title, expected_lines)
  is_expected.to contain_concat__fragment(title)
  content = subject.resource('concat::fragment', title).send(:parameters)[:content]
  expect(content.split("\n") & expected_lines).to match_array(expected_lines)
end

def verify_concat_fragment_exact_contents(subject, title, expected_lines)
  is_expected.to contain_concat__fragment(title)
  content = subject.resource('concat::fragment', title).send(:parameters)[:content]
  expect(content.split(/\n/).reject { |line| line =~ /(^#|^$|^\s+#)/ }).to match_array(expected_lines)
end